REMARKS 

In the Office Action dated September 4, 2009, claims 2-6 were rejected under 35 U.S.C. 
§ 103(a) as obvious over U.S. Patent Publication No. 2003/0172177 to Kersley et al. ("Kersley") 
in view of U.S. Patent Publication No. 2002/0190356 to Buechler et al. ("Buechler") as 
evidenced by English, ADA 95: The Craft of Object-Oriented Programming, "Glossary" 
("English"). Applicants respectfully traverse the rejections for the reasons set forth below. 

A. Claims 2-6 Are Not Obvious Over Kersley, Buechler and English 

AppUcants have invented a device verification method which provides a single flag for each 
of a plurality of packet classes . As recited, the single flag can have either a first state (e.g., "0" to 
indicate that the packet class has not been tested) or a second state (e.g., "1" to indicate that the 
packet class has been tested). When a packet from a packet class is generated, the single flag for that 
packet class is checked to see if it is in a first state, and if so, that packet is used to test the device for 
that packet class and the flag is changed to the second state. See, e.g., claim 2. On the other hand, if 
the single flag for that packet class is in a second state, the packet is not used to test the device for 
that packet class. See, e.g., claim 3. In this way, a device is tested by packet class since a packet 
within each packet class will only be used to test the device if the flag for that packet class has 
not been set to the second state. With Apphcants' invention, packets need not be stored in 
memory, but can instead be "generated" as claimed (e.g., randomly), and each generated packet in a 
given packet class can be checked against the flag for that packet class to determine if the packet will 
be used to test the device. This approach eliminates the costs associated with storing all possible 
packets to be tested, and also eliminates the inefficient testing of devices with redundant packets by 
using a single flag for each packet class to determine if a generated packet in the packet class will be 
used to test the device. 

In rejecting claims 2-6 as obvious over Kersley, Buechler and English, the Examiner 
asserts that Kersley' s disclosed method for verification of a device-under-test (Kersley, Fig. 2, ^ 
5-7, 18, 21-22, 35, and 43) meets the claim requirements except for variously recited 
requirements of (1) "providing a flag, which may be of a first or a second state, for each of the 
plurality of packet classes" (claims 2-6); (2) testing the device "if the flag of the packet class of 
the generated packet is in the first state" (claims 2-3 and 5-6); (3) not testing the device "if the 
flag of the packet class of the generated packet is in the second state" (claims 3-6); and (4) 
"changing the flag of the packet class of the generated packet to the second state" if the flag of 
the packet class of the generated packet is in the first state (claims 2 and 5-6). See, Office 
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Action, pp. 2-6. To overcome these deficiencies in Kersley's disclosure, the Examiner cites 
Buechler's disclosure (Buechler, 78) of using "record flags" to assure that all required assay 
tests are performed and to avoid duplication of testing. Id., pp. 6-8. 

In reply. Applicants respectfully submit that a prima facie case of obviousness has not 
been established for claims 2-6 because the Examiner has not met the burden of showing that all 
the claim limitations are taught or suggested by the prior art. In re Rovka . 490 F.2d 981, 180 
USPQ 580 (CCPA 1974); In re Wilson . 424 F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 
1970). To make this showing of obviousness, three basic criteria must be met. First, there must 
be some suggestion or motivation, either in the reference itself or in the knowledge generally 
available to one of ordinary skill in the art, to modify the reference as proposed by the Examiner. 
Second, there must be a reasonable expectation of success. Finally, the prior art reference must 
teach or suggest all the claim limitations. The teaching or suggestion to modify the reference 
and the reasonable expectation of success must both be found in the prior art, not in Applicants' 
disclosure. MPEP §§ 2143.01-03. 

In this case, the rejection analysis appears to have mischaracterized the claimed invention 
by ignoring the requirement that a single flag be used for each packet class to determine: 

(1) whether the device is tested with the generated packet (as variously required in claims 
2-3 and 5-6 which require device testing "if the flag of the packet class of the generated 
packet is in the first state"); 

(2) whether the device is not tested with the generated packet (as variously required in 
claims 3-6 which require no device testing "if the flag of the packet class of the generated 
packet is in the second state"); and/or 

(3) whether the flag is changed to a second state (as variously required in claims 2 and 5- 
6 which require changing the flag state if the flag of the packet class of the generated 
packet is in the first state"). 

In short, Applicants have disclosed and claimed using a single flag for each packet class to drive 

and determine these various actions (test, not test, change flag state). 

While the Examiner has conceded that Kersley does not meet these flag-based 

requirements ( Office Action , pp 5-6),^ the attempted reliance on Buechler to remedy these 

deficiencies is misplaced since Belcher explicitly discloses using a pluralitv of record flags to 



^ Indeed, there would be no need in Kersley's system for using flags for each tested packet since Kersley 
teaches using a "packet database 142" to store "standard and/or custom headers, optional trailers as well 
as predefined payload data." See, Kersley, f 63. Why maintain a set of flags for each tested packet when 
the packets are all stored in the "packet database 142"? 



5 



track tests and prevent duplication. See, Buechler, ^ 78 ("In order to assure that all required tests 
are performed, and also to avoid duplication of testing, record flags or other techniques can be 
used when the database 464 is accessed to retrieve test instructions. For example, when 
fluorometer 100 accesses information system 408 to receive instructions for a particular test, that 
test is flagged as being performed such that subsequent accesses by this or another fluorometer 
100 will not retrieve the same test instructions. Once a test is completed and the results provided 
to information system 408, another flag can be set indicating the status of the test as being 
completed.") (emphasis added). Thus, Buechler teaches using a "record flags " such that a first 
flag is set when "fluorometer 100 accesses information system 408 to receive instructions for a 
particular test," and " another flag " is set when the test is completed. Rather than meeting the 
variously recited requirements in claims 2-3 and 5-6 of testing the device "if the flag of the 
packet class of the generated packet is in the first state," Buechler discloses accessing the test 
instructions without first checking the state of an associated flag for the test. Likewise, rather 
than meeting the variously recited requirements in claims 3-6 of not testing the device "if the flag 
of the packet class of the generated packet is in the second state," Buechler discloses accessing 
"another flag" (not the same flag) to see if the test has been completed. Finally, rather than 
meeting the variously recited requirements in claims 2 and 5-6 of changing the flag to the second 
state "if the flag of the packet class of the generated packet is in the first state," Buechler 
discloses setting "another flag can be set" (not the same flag) "[o]nce a test is completed and the 
results provided to information system 408." In sum, Buechler uses two flags, not one flag as 
claimed, and sets the flags in response to different triggers than claimed. Buechler' s use of 
multiple flags for each test should come as no surprise since Buechler's fluorometer testing 
scheme is concerned with only a limited number of tests, so there would be no significant 
penalty in tracking multiple flags for each test. In contrast, Applicants' disclosed verification 
scheme is being used to test devices with "several thousand different combinations" of possible 
packet classes being tested. See, Application , p. 1, lines 20-21. 

Another problem with the cited art is that neither Kersley nor Buechler disclose or suggest 
"providing a plurality of packet classes ." much less "providing a flag ... for each of the plurality of 
packet classes " as recited in each of the pending claims. On this point, AppUcants have carefully 
review the cited disclosure from Kersley (Fig. 2, ^ 5-7, 18, 21-22, 35, 43), but there is absolutely no 
teaching or suggestion of any "packet class," much less of providing a flag for each "packet class." 



6 



And while Buechler discloses maintaining a flag for each assay test performed by the fluorometer, 
there is not suggestion of maintaining a flag for a class of tests. Thus, there is simply no teaching or 
suggestion that the cited art combination provides "a plurality of packet classes" with a flag "for each 
of the plurality of packet classes," as recited in the claims. Instead of being concerned with testing 
by packet class, Kersley is concerned with verifying a device-under-test by "generating packets to 
simulate complex network packet traffic patterns to test and verify a device under test (DUT)." 
Kersley, paragraph 5. 

In addition to the missing claim requirements, Apphcants submit that a person having 

ordinary skill in the art would not have combined the Kersley and Buechler references in the first 

place. On this point, the Examiner asserts that: 

It would have been obvious to one of ordinaiy skill in the art at the time of the invention to 
modify/combine the feat\u-es of Kersley by using the above-recited features, as taught by 
Beuchler (sic), in order to provide a method s preventing dupUcation of testing, thus 
decreasing wasteful testing time and additional resources used by not performing tests that 
already have been performed (see Beuchler (sic) sections 0078). One could have 
implemented the teaching of Beuchler (sic)to the concept of test packets of Kersley, where 
flags are kept for the different. 

Office Action , p. 8 (emphasis added). While this quote is not entirely clear, the Examiner appears 

to be arguing that the "record flags" described by Buechler "could" have been used with 

Kersley 's packet-based verification system. But the proper legal standard is not what could a 

person having ordinary skill in the art do. Instead, the question is what would such a person do. 

And in this case, the Examiner has failed to show how a person skilled in the art would be 

motivated to combine the references. See, DyStar Textilfarben GMBH v. C. H. Patrick Co. , 464 

F.3d 1356, 80 USPQ2d 1641 (Fed. Cir. 2006) ("'[CJonclusory statements such as those here 

provided do not fulfill the agency's obligation' to explain all material facts relating to a 

motivation to combine."). As required by the recent KSR decision, the Examiner must provide 

"some articulated reasoning with some rationale underpiiming to support the legal conclusion of 

obviousness" and must "identify a reason that would have prompted a person of ordinary skill in 

the relevant field to combine the elements in the way the claimed new invention does." KSR v. 

Teleflex , 127 S. Ct. 1727, 82 U.S.P.Q.2d 1385 (2007). In addition, the Examiner must make 

"explicit" this rationale of "the apparent reason to combine the known elements in the fashion 

claimed," including a detailed explanation of "the effects of demands known to the design 

community or present in the marketplace" and "the background knowledge possessed by a 

person having ordinary skill in the art." Id. Anything less than such an explicit analysis does not 
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meet the requirement of a prima facie case of obviousness. 

Applicants respectfully submit that inclusion of Buechler's "record flags" with Kersley's 
verification system would not be made by a person having ordinary skill in the art. To add a flag 
storage requirement to Kersley's system which uses a "packet database 142" to store and 
generate packets as proposed by the Examiner would actually increase the requirements for 
storing and processing the flag information, and "record flags" would be unnecessary if the 
"packet database 142" already stores the packets. In other words, the proposed combination is 
improper because it would change the principle of operation of Kersley's system by addition 
additional and superfluous requirements for storing and processing record flags. See, MPEP § 
2 143. 01 (VI) ("If the proposed modification or combination of the prior art would change the 
principle of operation of the prior art invention being modified, then the teachings of the 
references are not sufficient to render the claims prima facie obvious.") (citing In re Ratti . 123 
USPQ 349 (CCPA 1959)). 

In the absence oi a. prima facie showing that the requirements of claims 2-6 are disclosed in 
or obvious over the prior art, or that the cited references would be combined in the first place, 
AppUcants request that the obviousness rejection of claims 2-6 be withdrawn and that the claims be 
allowed. 

CONCLUSION 

In view of the remarks set forth herein, Applicants respectfully submit that all pending 
claims are in condition for allowance. Accordingly, Applicants request that a Notice of 
Allowance be issued. Nonetheless, should any issues remain that might be subject to resolution 
through a telephone interview, the Examiner is requested to telephone the undersigned at 5 12- 
338-9100. 
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